From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi@qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi@qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi@qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces@qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi@qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi@qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi@qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx@qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi@qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx@qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi@qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi@qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi@qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi@qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root@tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx@qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root@tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi@qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi@qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx@qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi@qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi@qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi@qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi@qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi@qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi@qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:07 2006 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0001.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi@qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi@qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi@qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces@qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0001.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi@qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi@qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi@qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx@qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:32 2006 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi@qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx@qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi@qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi@qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0001.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi@qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi@qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root@tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx@qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root@tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi@qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi@qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx@qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi@qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi@qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi@qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi@qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0001.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi@qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi@qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:33 2006 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0002.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi@qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi@qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi@qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces@qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0002.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi@qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi@qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi@qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx@qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi@qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx@qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi@qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi@qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0002.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi@qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi@qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root@tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx@qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root@tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi@qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi@qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx@qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi@qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi@qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi@qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi@qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0002.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:26 2006 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:27 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:27 2006 Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi@qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Tue Mar 28 20:17:27 2006 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:27 2006 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:27 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx@qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:27 2006 Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:27 2006 Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:27 2006 Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi@qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Tue Mar 28 20:17:27 2006 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi@qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:27 2006 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx@qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0003.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0003.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0003.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0003.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0004.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0004.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0004.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0004.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0005.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0005.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0005.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0005.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0006.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0006.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0006.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0006.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0007.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0007.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0007.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0007.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0008.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0008.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0008.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0008.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0009.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0009.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0009.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0009.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0010.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0010.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0010.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0010.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0011.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0011.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0011.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0011.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0012.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0012.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0012.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0012.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0013.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0013.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0013.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0013.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0014.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0014.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0014.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0014.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0015.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0015.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0015.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0015.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0016.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0016.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0016.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0016.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0017.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0017.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0017.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0017.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0018.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0018.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0018.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0018.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0019.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0019.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0019.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0019.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0020.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0020.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0020.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0020.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0021.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0021.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0021.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0021.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0022.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0022.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0022.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0022.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0023.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0023.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0023.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0023.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0024.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0024.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0024.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0024.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0025.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0025.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0025.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0025.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0026.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0026.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0026.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0026.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0027.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0027.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0027.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0027.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0028.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0028.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0028.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0028.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0029.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0029.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0029.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0029.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0030.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0030.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0030.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0030.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0031.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0031.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0031.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0031.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0032.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0032.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0032.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0032.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0033.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0033.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0033.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0033.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0034.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0034.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0034.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0034.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0035.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0035.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0035.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0035.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0036.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0036.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0036.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0036.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0037.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0037.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0037.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0037.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0038.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0038.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0038.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0038.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0039.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0039.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0039.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0039.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0040.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0040.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0040.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0040.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Feb 5 13:18:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 13:18:06 -0700 (MST) Subject: [Rxtx] Gentoo question In-Reply-To: <1139166021.23050.6.camel@localhost> References: <1139166021.23050.6.camel@localhost> Message-ID: Hi Paul I guess we are top posting :) Thats a very interesting link as I've built everything except hppa in the toybox and ppc mac os which I dont understand on gentoo. Maybe it means something else. the sh3/4 needs a one line fix to compile. more or less, I've shown that entire page can be green. ftp://ftp.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ I dont know if 80% of them work but I suspect so. On Sun, 5 Feb 2006, -- wrote: > Currently there is no ebuild for the new release, only a bugzilla entry. > I hope they will add it to gentoo portage soon. > > http://packages.gentoo.org/search/?sstring=rxtx > > This is the search for current release. > > On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: >> What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla >> entry we fixed for now. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 14:26:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 14:26:40 -0700 (MST) Subject: [Rxtx] Serial port ownership question In-Reply-To: References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > I can confirm that this is the case (only root ownership of > serial ports, under fedora 4). > Wow, what were they thinking?! > - DL > >> I've found that the newer kernels have the serial ports owned by root. >> For example, >> >> $ls -al /dev/tty* >> crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >> crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >> crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >> crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >> crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >> ... This is just not a problem jcp or such are going to solve. Its a platform spitwad fight. But do look at pam. In fact thats what Sun is doing too. Maybe Linux followed their lead.. I'm not a pam guy. I've spent 16 hours trying to understand it but your users wont :) Solution? I have no clue. Its two tangent mentalities from my perspective. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 21:41:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 21:41:07 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. Message-ID: My brother is in from germany. I'm not going to finish the wiki at all tonight. I'll do it tomorrow or if someone does a wiki between now and then I'll just point there. :) After that I'm taking almost 2 weeks off. I have to do a technical presentation on something other than rxtx. I doubt it will be usb now. That was discusting. I'll find something cool with community! Like rxtx :) bye. -- Trent Jarvi tjarvi at qbang.org From lux at diesel-research.com Sun Feb 5 22:02:06 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 22:02:06 -0700 Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: References: Message-ID: <1139202126.3213.4.camel@zd7280> usb ? Tell me more... I need that too. On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: > My brother is in from germany. I'm not going to finish the wiki at all > tonight. I'll do it tomorrow or if someone does a wiki between now and > then I'll just point there. :) > > After that I'm taking almost 2 weeks off. I have to do a technical > presentation on something other than rxtx. I doubt it will be usb now. > That was discusting. > > I'll find something cool with community! Like rxtx :) > > bye. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kim Lux, Diesel Research Inc. From tjarvi at qbang.org Sun Feb 5 22:49:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 22:49:28 -0700 (MST) Subject: [Rxtx] wiki delay until tomorrow night. In-Reply-To: <1139202126.3213.4.camel@zd7280> References: <1139202126.3213.4.camel@zd7280> Message-ID: On Sun, 5 Feb 2006, Kim Lux wrote: > usb ? Tell me more... I need that too. usb is a very proper design. Thats all it is. > > > > On Sun, 2006-02-05 at 21:41 -0700, Trent Jarvi wrote: >> My brother is in from germany. I'm not going to finish the wiki at all >> tonight. I'll do it tomorrow or if someone does a wiki between now and >> then I'll just point there. :) >> >> After that I'm taking almost 2 weeks off. I have to do a technical >> presentation on something other than rxtx. I doubt it will be usb now. >> That was discusting. >> >> I'll find something cool with community! Like rxtx :) >> >> bye. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0041.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0041.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0041.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Feb 1 13:47:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 13:47:59 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild Message-ID: I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 14:19:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 13:19:00 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Trent, We verified that the writeArray is NOT a problem when NOT using the Digi PortServer. We are following that thread now. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 12:48 PM To: rxtx at qbang.org Subject: [Rxtx] New Linux binary in lastbuild I inadvertantly compiled linux bins with the wrong gcc (4.1?). I think this is why the linux 2.4 enterprise linux was not working. I've recompiled the same source with gcc 2.96 and placed it in lastbuild. I've also managed to start building cross compilers after several attempts at creating sane chroots. They are spitting out as fast as possible with my 1.5 ghz/256 meg machine. I don't know if I'll stop making cross compilers today or tomorrow but thats when the bins will be released. I wont have to do this again for a while I hope. The next time it will be much faster. If people are interested when I'm done, I could burn dvds of the cross building environment and send them out. It really is a pain if you don't start on the right foot. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Feb 1 15:11:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 15:11:17 -0700 (MST) Subject: [Rxtx] New Linux binary in lastbuild In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Wed Feb 1 15:41:33 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Wed, 1 Feb 2006 14:41:33 -0800 Subject: [Rxtx] New Linux binary in lastbuild Message-ID: Unfortunately they're not Java people. I'll talk to them tomorrow and see if they have any timeouts inherent in their device driver that could be screwing us both up. I'll fill you in if I find anything out. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, February 01, 2006 2:11 PM To: RXTX Developers and Users Subject: RE: [Rxtx] New Linux binary in lastbuild On Wed, 1 Feb 2006, Morpeth, Chris wrote: > Trent, > > We verified that the writeArray is NOT a problem when NOT using the Digi > PortServer. We are following that thread now. > Hi Chris I'd be glad to work with them if it helps. I'm not sure whats up. Maybe it is something rxtx is doing. I can give them a complementary copy of rxtx :) -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Saul.Finkelstein at sbcglobal.net Wed Feb 1 18:09:45 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 01 Feb 2006 17:09:45 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <20060130172403.GA10728@freehold.crocodile.org> References: <20060130172403.GA10728@freehold.crocodile.org> Message-ID: <43E15BD9.5070608@sbcglobal.net> Vadim Tkachenko wrote: > My guess is that David is extremely busy and jUSB just > slipped out of his priority list. Trent Jarvi wrote: > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ Gerrit Telkamp wrote: > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > [...] > > Ok, to get compatible to the Java Specification Request > 80 might be difficult going this way, but libusb is more > probising than the "offical" way. Trent Jarvi wrote: > If I read things correctly, the JCP did like I've seen > before; blindside projects like a 600 lb barnie the > dinosaur flinging its tail in a china shop. The 600 lb > barnie is easy to get used to. Its the blindsiding that > takes the steam out of projects. Folks, I'm not sure of the makeup of this list, but let me add my opinion concerning this thread. As a professional software developer that makes products that people use and that I have to support, I'm not interested in basing my product on some hacks that are out there and which were done because people don't like to work within an existing framework that consists of other developers and other organizations that are trying to develop an API and an implementation that is stable, feature-rich and supported by more than one guy on his Linux box in his bedroom when he seems to have some time for it in between watching episodes of Lost. Sure, organizations like the JCP can appear to be big and cumbersome at times, but they (and other similar organizations) exist so that we don't have a mish-mash of random APIs that part-time developers threw together to solve The Problem De Juer. The function of organizations like the JCP is to develop APIs and implementations that work for a lot of different applications and in a lot of different environments. Think for a moment if no one followed the Internet RFC's because the RFC process was "too cumbersome" and it sure would be a lot faster just to hack something together in your spare time to let one Linux box talk to another Linux box over the net - that is, until you got tired of that project and moved on to something else. Where would we be today in terms of how universally technologies such as Ethernet and WiFi are available and interoperable? As for the comment on the JCP being a "600 lb barnie the dinosaur" I have to ask - have any of you (with the exception of Paul Klissner) ever worked with the JCP on anything, or are the comments on the JCP just a knee-jerk reaction that is based on emotion rather than facts? Saul From tjarvi at qbang.org Wed Feb 1 22:10:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 1 Feb 2006 22:10:41 -0700 (MST) Subject: [Rxtx] Pending Download/Install Issues Message-ID: I just wanted to mention this so Doug could think about it a little. Maybe others will have some thoughts. I'm creating cross compilers to have binaries for as many platforms as possible. Linux is going to be about 30 different binaries. Net and FreeBSD will bring it around 50-60 total I'm guessing. Then there will be a second pass with uclib for embeded devices. It's going to balloon. rxtx uclib for s390 does not make a great deal of sense but at this point. Java may not even run on everything. Some of these are for embeded devices obviously. But I know people use rxtx on them. I'm just swathing with hairy scripts. I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and maybe x86 freebsd in a zipfile. The rest I'll just put in a directory structure on ftp by OS, cpu, libc and call it the Toybox-version. alpha-unknown-linux-gnu/ arm-9tdmi-linux-gnu/ armeb-unknown-linux-gnu/ arm-iwmmxt-linux-gnu/ arm-softfloat-linux-gnu/ arm-unknown-linux-gnu/ i686-unknown-linux-gnu/ mips-unknown-linux-gnu/ sparc64-unknown-linux-gnu/ sparc-unknown-linux-gnu/ ... Any thoughts? -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Thu Feb 2 02:24:12 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Thu, 2 Feb 2006 10:24:12 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43E15BD9.5070608@sbcglobal.net> References: <20060130172403.GA10728@freehold.crocodile.org> <43E15BD9.5070608@sbcglobal.net> Message-ID: <355558406.20060202102412@domologic.de> I think everyone agrees with you that JCP is a very important instrument to standardize the Java technology. There is no alternative solution. But unfortunately, the real world is more complex. If I would have to develop software for a project where USB is a requirement, I would prefer to implement this in Java using a non-standarized USB library than to implement this in C using the Windows API. You can not go to your customer and tell him "Oh, sorry for the bugs, but they are caused by a library that has not been developed by me". And also if you think of RxTx - this project was born because the official and standarized way had chuckholes. Sometimes its better to go an unconvential way than to wait until the cows comes home. Gerrit. > Vadim Tkachenko wrote: >> My guess is that David is extremely busy and jUSB just > > slipped out of his priority list. > Trent Jarvi wrote: > > And we have the hobby guys trying to look like professionals: > > http://jusb.sourceforge.net/ > Gerrit Telkamp wrote: > > In my opinion the easiest & most promising way to get a > > platform-independent library for USB is to write a JNI > > wrapper for libusb (maybe using the gnu.io.*-namespace?). > > > > [...] > > > > Ok, to get compatible to the Java Specification Request > > 80 might be difficult going this way, but libusb is more > > probising than the "offical" way. > Trent Jarvi wrote: > > If I read things correctly, the JCP did like I've seen > > before; blindside projects like a 600 lb barnie the > > dinosaur flinging its tail in a china shop. The 600 lb > > barnie is easy to get used to. Its the blindsiding that > > takes the steam out of projects. > Folks, I'm not sure of the makeup of this list, but let > me add my opinion concerning this thread. As a professional > software developer that makes products that people use and > that I have to support, I'm not interested in basing my > product on some hacks that are out there and which were > done because people don't like to work within an existing > framework that consists of other developers and other > organizations that are trying to develop an API and an > implementation that is stable, feature-rich and supported > by more than one guy on his Linux box in his bedroom when > he seems to have some time for it in between watching > episodes of Lost. > Sure, organizations like the JCP can appear to be big and > cumbersome at times, but they (and other similar organizations) > exist so that we don't have a mish-mash of random APIs that > part-time developers threw together to solve The Problem > De Juer. The function of organizations like the JCP is to > develop APIs and implementations that work for a lot of > different applications and in a lot of different environments. > Think for a moment if no one followed the Internet RFC's > because the RFC process was "too cumbersome" and it sure > would be a lot faster just to hack something together in > your spare time to let one Linux box talk to another Linux > box over the net - that is, until you got tired of that > project and moved on to something else. Where would we be > today in terms of how universally technologies such as > Ethernet and WiFi are available and interoperable? > As for the comment on the JCP being a "600 lb barnie > the dinosaur" I have to ask - have any of you (with the > exception of Paul Klissner) ever worked with the JCP on > anything, or are the comments on the JCP just a knee-jerk > reaction that is based on emotion rather than facts? > Saul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Feb 2 06:54:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 02 Feb 2006 08:54:38 -0500 Subject: [Rxtx] Pending Download/Install Issues In-Reply-To: References: Message-ID: Hi All, I like the idea of making sure that there is one platform upon which we can build for many. This enables the creation of a master copy of the source code. Having multiple copies of the source code floating around is a fruitful source of bugs, for me. When source is updated with out the version number being updated the bug bites with a vengeance. The approach, outlined below, also addresses the deployment itch. I have been using signed jars, in jnlp, to download RXTX with web-start. Beaming over signed jar files (for applications) might be just as good. The approach requires, however, that we either obtain write access to sensitive areas of the jdk home directory, or use reflection to hack into the java.library.path API to enable its updating (which seems, oddly enough, to work!). So, if we obtain a consistent deployment of signed jar files that contain the binary, it would be idea, IMHO. Authors could check for the binary, recover from the error that results when it is not there, then load it from the web. During the loading process, it is a simple matter to verify the jar signing. The Net effect will be to create a library that can be deployed automatically. This approach, if successful, directly impacts the configuration problem for native method maintainers across the globe. It impacts RXTX, JAI, Java 3D, etc...IMHO. Gee, perhaps we should get a software patent ;) Any IP lawyers out there? - Doug >I just wanted to mention this so Doug could think about it a little. >Maybe others will have some thoughts. I'm creating cross compilers >to have binaries for as many platforms as possible. Linux is going >to be about 30 different binaries. Net and FreeBSD will bring it >around 50-60 total I'm guessing. Then there will be a second pass >with uclib for embeded devices. It's going to balloon. > >rxtx uclib for s390 does not make a great deal of sense but at this >point. Java may not even run on everything. Some of these are for >embeded devices obviously. But I know people use rxtx on them. I'm >just swathing with hairy scripts. > >I think for ftp from qbang, I'll put x86 linux,mac os x, win32 and >maybe x86 freebsd in a zipfile. The rest I'll just put in a >directory structure on ftp by OS, cpu, libc and call it the >Toybox-version. > >alpha-unknown-linux-gnu/ >arm-9tdmi-linux-gnu/ >armeb-unknown-linux-gnu/ >arm-iwmmxt-linux-gnu/ >arm-softfloat-linux-gnu/ >arm-unknown-linux-gnu/ >i686-unknown-linux-gnu/ >mips-unknown-linux-gnu/ >sparc64-unknown-linux-gnu/ >sparc-unknown-linux-gnu/ >... > >Any thoughts? > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 00:22:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2006 00:22:46 -0700 (MST) Subject: [Rxtx] Update Message-ID: I wanted to release mips, ppc and arm binaries. These are everything from handheld devices to Apple hardware running linux (linux people love mac hardware). It's going to work! But there are still 4 more hours of compiling cross compilers to go to finish ppc. I'm going to get some sleep as I expect a call early in the morning. So here are the platforms that compiled libc (99% chance they will work). ./alpha-unknown-linux-gnu/lib/libc.so ./arm-9tdmi-linux-gnu/lib/libc.so ./armeb-unknown-linux-gnu/lib/libc.so ./arm-iwmmxt-linux-gnu/lib/libc.so ./arm-softfloat-linux-gnu/lib/libc.so ./arm-unknown-linux-gnu/lib/libc.so ./armv5b-softfloat-linux/lib/libc.so ./arm-xscale-linux-gnu/lib/libc.so ./i386-unknown-linux-gnu/lib/libc.so ./i686-unknown-linux-gnu/lib/libc.so ./ia64-unknown-linux-gnu/lib/libc.so ./m68k-unknown-linux-gnu/lib/libc.so ./mipsel-unknown-linux-gnu/lib/libc.so ./mips-unknown-linux-gnu/lib/libc.so ./powerpc-405-linux-gnu/lib/libc.so ./powerpc-440-linux-gnu/lib/libc.so ./powerpc-604-linux-gnu/lib/libc.so ./powerpc-7450-linux-gnu/lib/libc.so ./powerpc-750-linux-gnu/lib/libc.so ./sparc64-unknown-linux-gnu/lib64/libc.so ./sparc-unknown-linux-gnu/lib/libc.so ./x86_64-unknown-linux-gnu/sys-root/usr/lib64/libc.so Still to coe are cygwin/mingw s390, ppc 860 and ppc 970 So this means everything will be generated from the same source for almost 30 platforms. After thats done, I'll release the bins and continue in this order: freebsd netbsd opensolaris (which should work on Solaris) darwin (dmitry? thoughts? is this binary compatible?) Then the same thing as much as possible with uclibc (embeded libc). The selection of the order is what I expect to be easy to setup first. I'll try them all though. Its just a computer grinding in the corner. When completed, I can move this all to a dual opteron with silly resources. It just isnt possible to create crosscompilers in a mixed 32/64 bit environment. The configuration gets all confused. So it should be just a quick script and everything compiles. The big ones that 'just wont work' are wince and w64. These use a binary format gcc does not currently support. I see some people are working on it though. Someone with the proper tools would have to do that. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 00:25:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 00:25:18 -0700 (MST) Subject: [Rxtx] Update Message-ID: The tools are made. Almost all of them work. I couldnt get hppa, cris and s390x (64 bit) working. I can get those later by installing glibc from other sources. I still have cleanup to do but this is far as I go before release. mips, ppc and arm are compiling (plus some). Here is what is building now: for i in *-*-*;do (cd $i/.libs;echo --------- $i --------; file -b librxtxSerial-2.1-7.so);done --------- alpha-unknown-linux-gnu -------- ELF 64-bit LSB shared object, Alpha (unofficial), version 1 (SYSV), not stripped --------- arm-9tdmi-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armeb-unknown-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-iwmmxt-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-softfloat-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- arm-unknown-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- armv5b-softfloat-linux-gnu -------- ELF 32-bit MSB shared object, ARM, version 1 (ARM), not stripped --------- arm-xscale-linux-gnu -------- ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped --------- i386-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- i686-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped --------- ia64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped --------- m68k-unknown-linux-gnu -------- ELF 32-bit MSB shared object, Motorola 68020, version 1 (SYSV), not stripped --------- mipsel-unknown-linux-gnu -------- ELF 32-bit LSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- mips-unknown-linux-gnu -------- ELF 32-bit MSB shared object, MIPS, MIPS-I version 1 (SYSV), not stripped --------- powerpc-405-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-440-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-604-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped --------- powerpc-7450-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-750-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- powerpc-860-linux-gnu -------- ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped --------- s390-ibm-linux-gnu -------- ELF 32-bit MSB shared object, IBM S/390, version 1 (SYSV), not stripped --------- sh3-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sh4-unknown-linux-gnu -------- ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), not stripped --------- sparc64-unknown-linux-gnu -------- ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped --------- sparc-unknown-linux-gnu -------- ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped --------- x86_64-unknown-linux-gnu -------- ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped I think s390 should be 31 bits. I also had to modify rxtx to get sh* compiling. But thats enough for testing. Tomorrow I just polish the scripts, package, document and release. I wont be doing more with Linux. I'll be moving to freebsd next. Its about as big and probably harder to get working with my experience but should go. Almost all of this is going into the ToyBox. People can find them if they need them. We will just package the most popular ones together in a zip file. Maybe Doug will find some cool things to do with all of this. The builds go fairly fast on the opteron system so this will just be a call to a script next release. I'll give anyone that wants a copy of the crosscompilers on a couple dvds (its 5 gigs right now) with everything ready to compile rxtx when I finish. I'm only using open source so there are no issues. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 12:59:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 12:59:04 -0700 (MST) Subject: [Rxtx] Updated http://www.rxtx.org/porting.html Message-ID: Feedback is welcome. I'm also putting up a wiki I hope will eventually replace these pages today. More to come. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 13:39:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 13:39:09 -0700 (MST) Subject: [Rxtx] Front Page Announcement Message-ID: Don't bother looking for links and downloads for another few hours. With rxtx 2.1-7pre17 we did extensive testing I can't talk about. The Changes that the community have contributed now make those test results rather meaningless in the big picture and they will have to be done again. This is a great thing but I just want to give some background why I thought it was best to leave pre17 as the default download for end users while we progressed through pre22. If you are a company working on the side, 2.1-7 is where you want to merge with head. 2.1-8 will be comming not far down the line but it would be to everyones advantage if we all work off 2.1-7. That also explains why this front page announcement is going to be rather large: # Sat Feb 4 2006 RXTX 2.1-7 (Final) Source and Binaries are now Available! Dont confuse this with RXTX 2.1-7pre... This is the Final release of 2.1-7. RXTX 2.0-7 will follow after Sun releases a new version that resolves incompatabilities. They have been very cooperative but things take time (think May). Mac OS X x86/universal binaries/install fixes Dmitry Markman source catch exceptions on flush() so close() works. Adam Walsh source more close() performance fixes ?vind Harboe source Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul source source %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki source System.gc() slows down close() too much. ?vind Harboe source Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp source CNI retry on EINTR CNI Ignore SIGXCPU as GCJ garbage collection uses this too. Mark Anderson CNI Patch to avoid having the SIGPWR signal interrupt select() Mark Anderson CNI debug message cleanups and fd fix Mark Anderson Dont override system properties Klaus Kierer W32 build fixes and Locking fixes Dave Acker Mac OS X auto* build fixes liblockdev support dereferencing type-punned pointer will break strict-aliasing rules. Fixed. x86_64 Linux Fixes fixes BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 I really should trash these 1997 looking web pages. I guess I like them because my brother Keane learned how to do html on them long ago. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 17:16:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 17:16:48 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: This is a page for people who want to have links to their projects that use rxtx (open or closed source but we tell people up front which it is). Search engines eat that stuff up and it helps your project be found more than being in a hall of fame :)
  • Remotej[Source] RemoteJ is an application for adding remote control capability to your k750 like mobile phone. (Trent says wow. I never expected rxtx on phones.)
  • There was another project here. I can't find it in my 1600 emails. If you could kindly repost or send me an email off the list I'd appreciate it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Feb 4 19:24:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Feb 2006 19:24:17 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download Message-ID: rxtx-2.1-7 prepresents over two years of community cooperation bringing rxtx to new levels of stability and functionality. I'm excited to announce that we are ready to release it. Maintainers get all the fun jobs. I'm sure there will be more bugs and feature requests but this is a milestone in the project. The changes are to many to mention. Please see: http://www.rxtx.org/changes.html The first version of our binaries (we wont change 2.1-7 source but we may change the builds if problems show up is: ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip We obviously provide the source under the LGPL license. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip See http://www.rxtx.org/download.html for more information. New with this release is the ToyBox. When you figure it out rxtx works on potentially over 100 platforms. Most people want the most common desktops. But we like toys. Embeded toys, Enterprise toys, we like them all. A start at filling the ToyBox with rxtx versions for your favorite toy has begun. ftp://ftp.qbang.org/pub/rxtx/ToyBox Another new feature which is in beta form right now is Dr. Douglas Lyon's supergizmo installer. Sometimes it does super things. Sometimes you let him know there are problems. The supergizmo installer can be found here. http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp Also new with this release is A bug reporting system. It will report all changes to a mail-list shortly but for now you can look at the great graphics and smile (or laugh). http://bugzilla.qbang.org One last feature that is being added but is still being worked on is a Wiki for documentation. It turns out many users don't like to read code to know how to use rxtx. After 9 years of not believing it, we at rxtx thought maybe it was time. A wiki will be forming. The hope is users and developers alike will be able to improve the already tremendous documentation rxtx provides :) http://rxtx.qbang.org/wiki [The wiki will be born late tonight] Many thanks to the developers that have helped improve rxtx and especially the users that helped us find problems. May the relationship continue. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 03:59:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 05:59:48 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: Hi All, First, let me say: Trent: You are doing an AMAZING job! I was wondering if there is a way to automate the creation of all the binaries (for all the platforms) from the source code? When I do a configure and a make, it just makes the binaries for one platform. I have a feeling that the macosx build is still not automated...but my gut tells me I should be able to do that (how, I don't know)... but it does seem possible (albeit, difficult). Am I correct about that? I am thinking of making a no-lock version so that you can have an install, for linux, that does not require you to be a system admin. Yes, I know that it is unsafe, but the present locking system makes configuration overhead a bit high, IMHO. Thanks! - Doug >rxtx-2.1-7 prepresents over two years of community cooperation >bringing rxtx to new levels of stability and functionality. > >I'm excited to announce that we are ready to release it. >Maintainers get all the fun jobs. I'm sure there will be more bugs >and feature requests but this is a milestone in the project. > >The changes are to many to mention. Please see: > > http://www.rxtx.org/changes.html > >The first version of our binaries (we wont change 2.1-7 source but we may >change the builds if problems show up is: > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7-bins.zip > >We obviously provide the source under the LGPL license. > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip > >See http://www.rxtx.org/download.html for more information. > >New with this release is the ToyBox. When you figure it out rxtx >works on potentially over 100 platforms. Most people want the most >common desktops. But we like toys. Embeded toys, Enterprise toys, >we like them all. A start at filling the ToyBox with rxtx versions >for your favorite toy has begun. > > ftp://ftp.qbang.org/pub/rxtx/ToyBox > >Another new feature which is in beta form right now is Dr. Douglas >Lyon's supergizmo installer. Sometimes it does super things. >Sometimes you let him know there are problems. The supergizmo >installer can be found here. > > >http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > >Also new with this release is A bug reporting system. It will >report all changes to a mail-list shortly but for now you can look >at the great graphics and smile (or laugh). > > http://bugzilla.qbang.org > >One last feature that is being added but is still being worked on is >a Wiki for documentation. It turns out many users don't like to >read code to know how to use rxtx. After 9 years of not believing >it, we at rxtx thought maybe it was time. A wiki will be forming. >The hope is users and developers alike will be able to improve the >already tremendous documentation rxtx provides :) > > http://rxtx.qbang.org/wiki > >[The wiki will be born late tonight] > >Many thanks to the developers that have helped improve rxtx and >especially the users that helped us find problems. May the >relationship continue. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From mtnvega at yahoo.com.br Sun Feb 5 04:36:18 2006 From: mtnvega at yahoo.com.br (Luiz Jr) Date: Sun, 5 Feb 2006 08:36:18 -0300 (ART) Subject: [Rxtx] Documentation Wiki Message-ID: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Hello, I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page Error 404 is what I'm receiving. So, where can I find the documentation? Thank you, Luiz --------------------------------- Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060205/b0bf71ca/attachment-0041.html From ideiglenes1 at freemail.hu Sun Feb 5 06:54:07 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 14:54:07 +0100 Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: References: Message-ID: <1139147647.23052.1.camel@localhost> Something is wrong with remotej project link. It doesnt show up on the page. Maybe href="" is missing? On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: > This is a page for people who want to have links to their projects that > use rxtx (open or closed source but we tell people up front which it is). > > Search engines eat that stuff up and it helps your project be found more > than being in a hall of fame :) > >
  • Remotej[Source] RemoteJ is an > application for adding remote control capability to your k750 like mobile > phone. (Trent says wow. I never expected rxtx on phones.) >
  • > > There was another project here. I can't find it in my 1600 emails. If > you could kindly repost or send me an email off the list I'd appreciate > it. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sun Feb 5 07:54:42 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 5 Feb 2006 09:54:42 -0500 Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: <95AA7AB7-8940-45F3-A7ED-89D278D524AB@mac.com> creating jnilib and jar shouldn't be any more difficult then on other platform but mac os x is a very user oriented OS, mac os x users are "spoiled" :-)) you have to give them installer however I think make's install target can do the job important part is to prepare the system for rxtx and run the following script (or similar) #!/bin/sh curruser=`sudo id -p | grep 'login' | sed 's/login.//'` echo $curruser if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi also installer package could be created with packagemaker command tool cd packagemaker -build -p RXTX_Tiger.pkg -f ./Install -ds -r ./Resources -proj RXTX_Tiger.pmproj file RXTX_Tiger.pmproj could be extracted from the file RXTX_Tiger.pmproj.sitx.hqx CVS repository contains RXTX_Tiger.pmproj.sitx.hqx file On Feb 5, 2006, at 5:59 AM, Dr. Douglas Lyon wrote: > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? Dmitry Markman From lux at diesel-research.com Sun Feb 5 09:37:02 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:37:02 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: <1139157422.4553.9.camel@zd7280> On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, > since I can not access the documentation wiki page I just started using them yesterday. Below is how I installed the libraries, if that helps. I used snippets of code from the SimpleWrite application here to get me going. http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html Instead of "import javax.comm.*;", use "import gnu.io.*;" which is gotten from RXTXcomm.jar, which you will need to include in your project references. I am working in Eclipse. BTW: there is no way to open a port without going through the port list and finding it. Maybe sometime in the future someone (me ?) will write a method called openSerialPort that allows the user to give a port identifier, such as "/dev/tty1" and return a port ready to use. It wouldn't take much to write that and it would save users a lot of code. Hope this helps. ======================================================================= 1) Figure out which java you are running, incase there is more than one installed. $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) 2) Find all the jre directories and the one from which you are currently running. kfind (jre) 3) cd to that directory plus /lib/i386 cd /usr/java/jre1.5.0_05/lib/i386 4) Copy the library files (*.so) to that directory. cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . 5) Check that the copy was successful ls librxtx* librxtxI2C.so librxtxRaw.so librxtxSerial.so librxtxParallel.so librxtxRS485.so 6) cd to the /lib/ext directory for your java. cd /usr/java/jre1.5.0_05/lib/ext 7) Copy the Jar files there cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . 8) Check that it was successful ls RXTX* RXTXcomm.jar Rxtx is now installed on your machine ready to use. =================================================================== -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:50:38 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:50:38 -0700 Subject: [Rxtx] Documentation Wiki In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158238.4936.1.camel@zd7280> I guess I should say that my install instructions were for the Linux OS, specifically Fedora Core 4. The approach should be the same on any Linux machine, although the target directories may be slightly different. On Sun, 2006-02-05 at 09:37 -0700, Kim Lux wrote: > On Sun, 2006-02-05 at 08:36 -0300, Luiz Jr wrote: > > Hello, > > > > I want to start using the RXTX libraries, but I would to know how, > > since I can not access the documentation wiki page > > I just started using them yesterday. > > Below is how I installed the libraries, if that helps. > > I used snippets of code from the SimpleWrite application here to get me > going. > http://java.sun.com/products/javacomm/reference/docs/API_users_guide_3.html > > Instead of "import javax.comm.*;", use "import gnu.io.*;" which is > gotten from RXTXcomm.jar, which you will need to include in your project > references. > > I am working in Eclipse. > > BTW: there is no way to open a port without going through the port list > and finding it. Maybe sometime in the future someone (me ?) will write > a method called openSerialPort that allows the user to give a port > identifier, such as "/dev/tty1" and return a port ready to use. It > wouldn't take much to write that and it would save users a lot of > code. > > Hope this helps. > > > ======================================================================= > 1) Figure out which java you are running, incase there is more than one > installed. > > $ java -version > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) > > > 2) Find all the jre directories and the one from which you are currently > running. > > kfind (jre) > > 3) cd to that directory plus /lib/i386 > > cd /usr/java/jre1.5.0_05/lib/i386 > > 4) Copy the library files (*.so) to that directory. > > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/bin/* . > > 5) Check that the copy was successful > > ls librxtx* > librxtxI2C.so librxtxRaw.so librxtxSerial.so > librxtxParallel.so librxtxRS485.so > > > 6) cd to the /lib/ext directory for your java. > > cd /usr/java/jre1.5.0_05/lib/ext > > 7) Copy the Jar files there > cp /home/krlux/Desktop/'Java Controls'/rxtx-linux/lib/ext/* . > > 8) Check that it was successful > > ls RXTX* > RXTXcomm.jar > > Rxtx is now installed on your machine ready to use. > > =================================================================== > > -- Kim Lux, Diesel Research Inc. From lux at diesel-research.com Sun Feb 5 09:58:18 2006 From: lux at diesel-research.com (Kim Lux) Date: Sun, 05 Feb 2006 09:58:18 -0700 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139157422.4553.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> Message-ID: <1139158698.4936.9.camel@zd7280> I've found that the newer kernels have the serial ports owned by root. For example, $ls -al /dev/tty* crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 ... If one tries to open such a serial port as a regulator user, one will get a permission denied error. To get around this problem, I do $su #chown krlux /dev/ttyUSB0 #exit which then lets me access the port as I need to as a regular user. I've got this problem with minicom, gtkterm and now my rxtx applications. There must be a work around other than chmod, but I don't know what it is. Can anyone explain this or how to make it work "properly", ie without having to do a chown ? -- Kim Lux, Diesel Research Inc. From ideiglenes1 at freemail.hu Sun Feb 5 10:55:18 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 18:55:18 +0100 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: <1139162118.23052.3.camel@localhost> If you have pam installed /etc/security/console.perms is the key to configure permission for like devices. Give enough group permissions there for the device, and after you can use it with users that are in group tty. On v, 2006-02-05 at 09:58 -0700, Kim Lux wrote: > I've found that the newer kernels have the serial ports owned by root. > For example, > > $ls -al /dev/tty* > crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty > crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 > crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 > crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 > crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 > ... > > If one tries to open such a serial port as a regulator user, one will > get a permission denied error. > > To get around this problem, I do > > $su > #chown krlux /dev/ttyUSB0 > #exit > > which then lets me access the port as I need to as a regular user. > > I've got this problem with minicom, gtkterm and now my rxtx > applications. > > There must be a work around other than chmod, but I don't know what it > is. > > Can anyone explain this or how to make it work "properly", ie without > having to do a chown ? > > From tjarvi at qbang.org Sun Feb 5 11:05:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:05:19 -0700 (MST) Subject: [Rxtx] http://www.qbang.org/projects.html In-Reply-To: <1139147647.23052.1.camel@localhost> References: <1139147647.23052.1.camel@localhost> Message-ID: Thanks Paul On Sun, 5 Feb 2006, -- wrote: > Something is wrong with remotej project link. It doesnt show up on the > page. Maybe href="" is missing? > > On szo, 2006-02-04 at 17:16 -0700, Trent Jarvi wrote: >> This is a page for people who want to have links to their projects that >> use rxtx (open or closed source but we tell people up front which it is). >> >> Search engines eat that stuff up and it helps your project be found more >> than being in a hall of fame :) >> >>
  • Remotej[Source] RemoteJ is an >> application for adding remote control capability to your k750 like mobile >> phone. (Trent says wow. I never expected rxtx on phones.) >>
  • >> >> There was another project here. I can't find it in my 1600 emails. If >> you could kindly repost or send me an email off the list I'd appreciate >> it. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> _______________________________________________ >> 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 tjarvi at qbang.org Sun Feb 5 11:10:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:10:26 -0700 (MST) Subject: [Rxtx] Gentoo question Message-ID: What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla entry we fixed for now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:13:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:13:55 -0700 (MST) Subject: [Rxtx] Documentation Wiki In-Reply-To: <20060205113618.30274.qmail@web53501.mail.yahoo.com> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> Message-ID: On Sun, 5 Feb 2006, Luiz Jr wrote: > Hello, > > I want to start using the RXTX libraries, but I would to know how, since I can not access the documentation wiki page > > Error 404 is what I'm receiving. > > So, where can I find the documentation? > I fell asleep lastnight without finishing the wiki :) I dont have any great content for it but will get it up today. It should not be 404. Which link did I mess up? It should be redirecting to www.qbang.org until the wiki is up. Our marketing department thinks it's a great idea to send people to www.qbang.org to increase sales and get more advert hits with our partners :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:23:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:23:50 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: On Sun, 5 Feb 2006, Dr. Douglas Lyon wrote: > Hi All, > First, let me say: > Trent: You are doing an AMAZING job! > > I was wondering if there is a way to automate > the creation of all the binaries (for all the platforms) from the source > code? > When I do a configure and a make, it just makes the binaries > for one platform. > > I have a feeling that the macosx build is still not automated...but > my gut tells me I should be able to do that (how, I don't know)... > but it does seem possible (albeit, difficult). Am I correct about > that? > > I am thinking of making a no-lock version so that you can have > an install, for linux, that does not require you to be a system admin. > > Yes, I know that it is unsafe, but the present locking system makes > configuration overhead a bit high, IMHO. > Hi Doug If you do the nolockfiles option in configure *please* put big hairy warnings up. There is Java and there is Unix. Java likes to think its a platform but it is on Unix too. Not doing Lock Files in Unix is very bad and I don't approve of it. (but you can do it :) When you first asked the question about 'building from one source' I knew what you need but man its not easy. Putting this together is probably worth while though and might help many java JNI projects later. I think it is possible but it needs all the crosscompilers. I honestly don't think I'll be done for 2 months. There are open source versions of solaris and Mac OS X. The companies behind them are _great_ at ABIs. Apple is constantly fixing things in gcc and catching them. Without 'knowing' I'm sure it will work. But I'm also possibly (probably) moving to Boston during this time. How this works with rxtx is the like I did with the toybox. Here is a crude example (and am I good at crude when need be). This probably wont paste well in pine. I'll be making dvds of these tools for everyone that wants them. I didnt do w32 in this build but it works the same as will Darwin and Open Solaris when the tools are done. for i in alpha-unknown-linux-gnu arm-9tdmi-linux-gnu armeb-unknown-linux-gnu arm -iwmmxt-linux-gnu arm-softfloat-linux-gnu arm-unknown-linux-gnu armv5b-softfloat -linux arm-xscale-linux-gnu cris-unknown-linux-gnu hppa-unknown-linux-gnu i386-u nknown-linux-gnu i686-unknown-linux-gnu ia64-unknown-linux-gnu m68k-unknown-linu x-gnu mipsel-unknown-linux-gnu mips-unknown-linux-gnu powerpc-405-linux-gnu powe rpc-440-linux-gnu powerpc-604-linux-gnu powerpc64-unknown-linux-gnu powerpc-7450 -linux-gnu powerpc-750-linux-gnu powerpc-860-linux-gnu s390-unknown-linux-gnu s3 90x-unknown-linux-gnu sh3-unknown-linux-gnu sh4-unknown-linux-gnu sparc64-unknow n-linux-gnu sparc-unknown-linux-gnu x86_64-unknown-linux-gnu do PATH=/opt/crosstool/gcc-3.4.4-glibc-2.3.5/$i/$i/bin/:/opt/crosstool/gcc-3.4.4-gl ibc-2.3.5/$i/bin:/opt/jdk1.5.0_01-rxtx-2.1/bin/:/bin:/usr/bin ../configure --host=i686-unknown-linux-gnu --target=$i; if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi make done -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Feb 5 11:33:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 11:33:14 -0700 (MST) Subject: [Rxtx] ewie-lockfiles Message-ID: What would people think if we added an option to configure for ewie lockfiles. http://www.urbandictionary.com/define.php?term=ewie&defid=1205859 ./configure --enable-ewie-lockfiles When done, rxtx would look at and respect lockfiles but would not create them. There are many options already in configure including liblockdev and the lockfileserver if I'm not mistaken but I see companies and people going towards no lockfiles which is the worst case of all. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Sun Feb 5 12:00:21 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 05 Feb 2006 20:00:21 +0100 Subject: [Rxtx] Gentoo question In-Reply-To: References: Message-ID: <1139166021.23050.6.camel@localhost> Currently there is no ebuild for the new release, only a bugzilla entry. I hope they will add it to gentoo portage soon. http://packages.gentoo.org/search/?sstring=rxtx This is the search for current release. On v, 2006-02-05 at 11:10 -0700, Trent Jarvi wrote: > What is the proper link for rxtx ebuilds at gentoo? I linked the bugzilla > entry we fixed for now. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Feb 5 12:00:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Feb 2006 12:00:27 -0700 (MST) Subject: [Rxtx] [Announce] rxtx-2.1-7 is Available for Download In-Reply-To: References: Message-ID: > if [ -f RXTXcomm.jar ]; then touch RXTXcomm.jar; fi Don't include that. I was looking at changes for 2.1-8 and just pasted my workspace script. It wont generate headers currently if you do that. Most of the compile time is creating the jar and we only use one jar on all platforms so I was tinkering and thinking. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Feb 5 12:10:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 05 Feb 2006 14:10:34 -0500 Subject: [Rxtx] Serial port ownership question In-Reply-To: <1139158698.4936.9.camel@zd7280> References: <20060205113618.30274.qmail@web53501.mail.yahoo.com> <1139157422.4553.9.camel@zd7280> <1139158698.4936.9.camel@zd7280> Message-ID: I can confirm that this is the case (only root ownership of serial ports, under fedora 4). Wow, what were they thinking?! - DL >I've found that the newer kernels have the serial ports owned by root. >For example, > >$ls -al /dev/tty* >crw-rw-rw- 1 root root 5, 0 Feb 5 02:06 /dev/tty >crw-rw---- 1 root root 4, 0 Feb 5 02:06 /dev/tty0 >crw------- 1 root root 4, 1 Feb 5 09:07 /dev/tty1 >crw-rw---- 1 root tty 4, 10 Feb 5 02:06 /dev/tty10 >crw-rw---- 1 root tty 4, 11 Feb 5 02:06 /dev/tty11 >... > >If one tries to open such a serial port as a regulator user, one will >get a permission denied error. > >To get around this problem, I do > >$su >#chown krlux /dev/ttyUSB0 >#exit > >which then lets me access the port as I need to as a regular user. > >I've got this problem with minicom, gtkterm and now my rxtx >applications. > >There must be a work around other than chmod, but I don't know what it >is. > >Can anyone explain this or how to make it work "properly", ie without >having to do a chown ? > > >-- >Kim Lux, Diesel Research Inc. > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx